home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14693 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.9 KB  |  85 lines
  1. Newsgroups: comp.object,comp.lang.c++,comp.lang.java
  2. Path: night.primate.wisc.edu!aplcenmp!hall
  3. From: hall@aplcenmp.apl.jhu.edu (Marty Hall)
  4. Subject: Re: Java: What's the Big Deal?
  5. Message-ID: <Dp757r.K5@aplcenmp.apl.jhu.edu>
  6. Organization: JHU/APL Research Center, Hopkins P/T CS Faculty
  7. References: <4jk4ee$7ri@newsbf02.news.aol.com> <1996Apr1.155416.12816@schbbs.mot.com>
  8. Date: Mon, 1 Apr 1996 18:40:39 GMT
  9.  
  10. In article <1996Apr1.155416.12816@schbbs.mot.com> shang@corp.mot.com writes:
  11. >
  12. >The more a program depends on GC, the more likely it will exhaust memory;
  13. >because the storage is collected only when all its references are
  14. >no longer valid, not at the time when all its references are no longer
  15. >used.
  16. [...]
  17. >The more a language depends on GC, the more likely its application will
  18. >exhaust memory [...]
  19.  
  20. One could also claim just the opposite: "A program/language that
  21. doesn't use GC is more likely to exhaust memory because of memory
  22. leaks". I could cite anecdotes of Lisp/Scheme/Smalltalk/Dylan vs C/C++
  23. applications where this is true, but of course in practice there are
  24. also plenty of counter-examples where using a particular garbage
  25. collection algorithm does in fact increase your memory requirements.
  26.  
  27. >because the storage is collected only when all its references are
  28. >no longer valid, not at the time when all its references are no longer
  29. >used. Be careful, never make a variable's lifetime unecessarily longer
  30. >than the required.
  31.  
  32. Surely this advice is true in a non-GC system also? Ie to avoid
  33. dangling pointers it is a good idea to get rid of references to the
  34. memory before you free it. Then the question becomes: "If you forget
  35. to get rid of all those references, is it better to have extra memory
  36. used as a result, or to risk dangling pointer errors?".
  37.  
  38. >With Java's array, memory will be smashed into millions of small
  39. >pieces.
  40.  
  41. There are also plenty of arguments that GC decreases the average
  42. overall fragmentation in real programs and that allocators in GC'd
  43. systems will be faster. Just as I don't buy the above argument as
  44. showing anything typical, I don't buy the "GC decreases fragmentation"
  45. argument either. Perhaps, but I'm not sure very many people know
  46. enough about the typical memory allocation/deallocation patterns in
  47. "real" programs to be able to tell. 
  48.  
  49. IMHO, the evidence so far suggests that expert handcrafted memory
  50. management and GC should have similar performance on the average. I'll
  51. take the GC for convenience sake (and because I may not be an expert
  52. at handcrafting memory management). But many situations are not
  53. "average". Also note that having GC in a language does not prevent you
  54. from managing your own memory anyhow (reusing resources, etc).
  55.  
  56. However, I'm no GC expert. A few sources to read from those who are:
  57.  
  58. A) Paul Wilson's survey of uniprocessor GC techniques. To appear in
  59. ACM's Computing Surveys:
  60. http://www.apl.jhu.edu/~hall/text/Papers/Bigger-GC-Survey.ps
  61. Also on ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
  62. IMHO, this is the best single place to start for people (like me :-)
  63. who don't know much about GC but want to learn more.
  64.  
  65. B) Henry Baker's paper archive:
  66. ftp://ftp.netcom.com/pub/hb/hbaker/home.html
  67.  
  68. C) Articles by Hans-J Boehm at ftp://parcftp.xerox.com/pub/gc/. Eg
  69.   1) ftp://parcftp.xerox.com/pub/gc/example.html --
  70.      A discussion showing that in some cases explicit allocation/deallocation
  71.      (malloc/free) can be computationally more expensive than garbage
  72.      collection. Note that he is not claiming that GC is faster in
  73.      practice, only refuting the claim that it *must* be slower.
  74.   2) ftp://parcftp.xerox.com/pub/gc/complexity.html. Discusses the 
  75.      complexity of mark-sweep vs. copying garbage collectors.
  76.      He attempts to refute the claims that copying collectors have
  77.      better paging performance due to compaction, and that the
  78.      asymptotic time complexity of copying collectors is necessarily
  79.      better.
  80.  
  81. Cheers-
  82.                         - Marty
  83. (proclaim '(inline skates))
  84. http://www.apl.jhu.edu/~hall
  85.